(Sun Microsystems, Inc.)(1997).iso/products/Unify/gifs/rgblogo2.GIF)
[Press Releases | Careers | Products | Corporate Info | Doing Business | Services | Home Page]
(Sun Microsystems, Inc.)(1997).iso/products/Unify/gifs/seybcov.gif) |
Patricia Seybold GroupProviding Strategic Guidance for Open,
|
|
Patricia Seybold GroupProviding Strategic Guidance for Open,
|
| Client/Server Applications Demand Direct Management | The spread of client/server applications is driving new approaches to management. Conventional network & systems management products have proven incapable of managing client/server modules. The alternative is direct application management. Direct application management is the monitoring, control, and tuning of the software modules that make up client/server applications. Direct application management gives application developers the opportunity to create robust, production-quality client/server applications by building management into their code |
| Direct Application Management Is a New Approach | A direct application management architecture automates the collection and forwarding of appropriate information about an application to consoles and other tools. In direct application management, developers decide which information about the modules they create is made available to agents. A complete direct application management solution meets six requirements. First, the architecture automates and simplifies the generation of application-specific management events and performance data. Second, the architecture supports many applications utilizing a variety of platforms. Third, the architecture integrates well with external management consoles and other applications. Fourth, the architecture scales to support large environments. Fifth, the architecture is easy to extend to address new management systems and new types of management data. Sixth, the architecture addresses all of the five management disciplines: fault, performance, configuration, security, and accounting management. |
| Four Approaches-One Is Best | Organizations have to choose from among four alternative architectures to manage their client/server environments. The first of these architectures relies on conventional network & systems management products, such as Hewlett-Packard OpenView and Sun's Solstice. The second alternative is application management APIs. The third is database-server management products. And the fourth is emerging application management architectures. Of the four, the last one is best suited to user requirements for client/server management. Only comprehensive application management architectures are designed to solve the complex problem of client/server application management. Unify's AppMan is a prototypical application management architecture, and it deserves serious consideration from user organizations considering client/server management solutions. |
| Management Must Be Built Into Client/Server Applications | Managing client/server applications is akin to playing detective. In both cases, accurate knowledge about the cause of an occurrence is hidden in evidence, from which you must infer the facts. In detective work, a confession from the suspect is preferred as the most direct way to the truth. In client/server application management, direct management of application code is preferred to piecing together causes and effects from various log files and protocol dumps. (See Illustration AM-1.) Today, organizations manage client/server applications using technologies designed to watch over and configure network devices and operating systems. The problem is that these conventional network & systems management technologies provide only indirect ways to monitor, control, configure, and optimize application modules. Applications exhibit behavior that can't be understood by studying network & systems management data. When applications misbehave, and network/systems management professionals must sift through hundreds or thousands of management events to find the cause of the problem. The result is high costs and frustrated users. Conventional technology makes client/server application management an expensive proposition. Like successful detective work, indirect management requires individuals that are highly trained, experienced, and very skilled. |
(Sun Microsystems, Inc.)(1997).iso/products/Unify/gifs/seyb10002.gif)
| The complexity of client/server applications is one reason that conventional management technology is failing in application management. Client/server designs break applications into two or more pieces: at minimum, a desktop "client" and a database server. The trend is toward designs in which an application is a collection of many components, some of which are developed in-house and some of which are acquired from third parties. Operational personnel can't modify the third-party pieces to make them manageable. The only practical alternative is to build management into those modules. | |
| High costs,
frustrated users, and the increasing use of client/server
applications in mission-critical roles are driving a change in
management technology. The change: Make application
management direct rather than indirect. Using direct
application management, developers build management into
client/server modules. This approach allows network/systems
management professionals to, for example, extract
"confessions" directly from client/server applications
rather than having to piece together the cause of a problem from
evidence. The result will be the first effective management of
client/server applications, lower costs, and increased user
satisfaction. | |
| Developers Must Become Participants in Application Management | The advent of direct application management
gives application developers new opportunities to create robust,
production-quality client/server applications. However, direct
application management requires new thinking by application
developers, and by the vendors of applications development tools.
Indeed, direct application management requires active participation
of the development community. Network and systems management
professionals and vendors of traditional management products cannot
complete the shift to direct management by themselves. There are four alternative approaches emerging for IS management and developers to choose from. The four are:
|
| What is Direct Application Management? | Direct application management is the monitoring, control, and tuning of the software modules that make up user applications. A direct application management architecture automates the collection and forwarding of appropriate information about an application to consoles and other tools. Direct application management is based on the concepts of managed objects, agents, and managers. The network management community has used those three concepts for many years. (See Illustration AM-2.) Agents collect management information from managed objects, and forward that information to managers for presentation and analysis by management professionals. Many in the industry think of managed objects as network devices, which passively contribute management data. However, managed objects may also be intelligent software modules that are active generators of management information about themselves. |
(Sun Microsystems, Inc.)(1997).iso/products/Unify/gifs/seyb10003.gif)
In network
management, vendors decide which management information is made
available to agents. In direct application management,
developers decide which information about the modules they
create is made available to agents. Developers, for example, can
flag events that will help prevent failure of the application.
Examples of application management information include:
|
| The Five Disciplines of Direct Application Management | Failure, or fault, management and performance
management are two of five "disciplines" associated with
the manager-agent architecture. Management disciplines are
categories of management information and the actions associated
with that information. The five disciplines are:
|
| Direct Application Management Must Fit Into Existing Management Structures | Products that seek to provide direct application management must fit into existing management systems. Organizations have already installed a wide variety of conventional network and systems management products. These products range from Hewlett-Packard OpenView, Sun's SunNet Manager, IBM's SystemView, and other Simple Network Protocol Manager (SNMP) products to BMC's Patrol, Tivoli Enterprise Console, Courier, and Sentry, HP's OperationsCenter, and other systems management products. Fortunately, all vendors of network, system, and application management products employ the manager- agent architecture. In many cases, these products use either standard formats and protocols or published APIs, which allow them to accommodate application-specific management information. |
| The Missing Link: Development Tools That Support Application Management | The current environment sets the stage for direct application management. The architecture (manager-agent) is well-understood. The formats and protocols are available. The missing ingredient is development tools designed to support direct application management. These tools began to appear in the market during 1995. However, as these products rolled out, it has become apparent that not all application management solutions are created equal. Some of the tools that support external monitoring and control of application modules don't fit into existing management environments. Others address only a subset of the functions required for direct application management. The pitfalls in choosing an incomplete or inadequate solution are serious for application developers and their colleagues in network and systems operations. |
| Six Requirements for a Complete Approach | A complete solution for direct application management meets the following six requirements.
|
| Requirement #1: Simple Generation of
Application Specific Events | IDEAL: AUTOMATIC GENERATION OF EVENTS AND PERFORMANCE METRICS. The ideal solution will provide many events automatically, and then make it easy for developers to design custom events. In most organizations, application development and network/systems operations are separate organizations. Application developers typically design and build their applications, then "toss them over the wall" to operations groups for deployment and ongoing maintenance. Direct application management requires that application developers take a greater degree of responsibility for the management of their code by identifying the key management events associated with that code. Application developers must be able do so without having to become systems management gurus. The top requirement of direct application management solutions, then, is to make identification and generation of application-specific management events and performance metrics straightforward for developers. To developers, productivity is a key concern. Developers will avoid-or even reject-direct application management solutions that get in the way. |
| Requirement #2: Architecture for Multiple Applications | UNDERSTANDING INTERRELATIONSHIPS IS ESSENTIAL. Application modules share use of client/server resources, and management professionals must be able to see and understand the resulting interrelationships between applications. In the old days of network and systems management, single-system monitoring utilities were the rule. Network operations centers typically were cluttered with monitors, each displaying statistics or readings from a different "key" network device. This approach ignored the important relationships between network devices. A condition in one device often caused slowdowns or failure in other devices. SNMP was created to allow management information from many network devices to be collected and manipulated by a single manager, which became commonly known as a management console. Today's network management center typically employs one or two powerful consoles to manage complex webs of devices and other facilities. The same principle applies to direct application management. Systems for monitoring, control, and tuning of single applications only will quickly add up to an unintegrated mess. Multiple consoles are impractical in direct application management for the same reason they didn't work in network management. The best direct application management solutions are designed as general architectures, not single application monitors. |
| Requirement #3: Support for External Management Systems | BEST SOLUTIONS INCLUDE SUPPORT FOR MULTIPLE
CONSOLES, PCs, AND PRE-BUILT AGENTS. Organizations will not
tear out their existing management environments to implement direct
application management. Rather, direct application management must
extend and leverage current management environments. Thus, a key
requirement of direct application management solutions is support
for external consoles and related systems. The manager-agent
architecture provides the foundation for this support.
Application-specific events can be forwarded to agents that
represent the external system. However, not all solutions support
external management systems equally well. The support varies along
three dimensions:
|
| Requirement #4: Scaleable Architecture | CRUCIAL: PRIORITIZATION AND FILTERING OF EVENTS. Some direct application management solutions simply make management events available to external consoles. These solutions can swamp a management environment with new data. Other solutions are designed to receive and prioritize application-specific management events and performance metrics, and forward appropriate information to consoles. The latter approach offers prioritized data, and is likely to scale more efficiently. A general-purpose architecture must be able to grow to accommodate increased volumes of data, users, and managed objects. In direct application management, scalability is determined by a solution's ability to handle a rising tide of management data. Data is delivered via management events, with a frequency that ranges from multiple events per second to one event per minute or so. Inevitably, the volume of management data grows dramatically as organizations deploy new applications and update existing applications. |
| Requirement #5: Easily Extensible Architecture | REQUIRED FOR EXPANSION: EASY ADDITION OF NEW AGENTS. Extensibility addresses expansion of a management environment with new applications, new management events, and new external management facilities. Despite all of the talk about "open APIs," extensibility remains the best test of any technology's openness, and direct application management solutions are no exception to this rule. To meet the challenge of extensibility, a direct application management solution must allow user organizations to easily add new agents and even to create agents to accommodate special requirements. In addition, developers must be able to create new management events to represent the important states and performance of their application modules. |
| Requirement #6: Comprehensive Architecture | KEY: ARCHITECTURE MUST ADDRESS ALL FIVE DISCIPLINES. The last requirement for application management is support for the five management disciplines: fault management, performance management, configuration management, accounting management, and security management. Most organizations make fault management their highest priority, reasoning that dealing with failures is the first order of business. However, as important as fault management is, it cannot be the limit of function in a direct application management solution. Performance management is equally important because user satisfaction with an application is usually defined by that application's performance. The same is true for the many solutions that focus on software distribution today. Software distribution and configuration management are important, but not a full solution. |
| Categorizing a Confusing Array of Alternatives | The market in management products and technology
offers a wide variety of confusing alternatives for direct
application management. Network and systems management specialists
are moving to add application-management features and functions to
their products. Vendors of middleware, databases, and other
client/server facilities are adding monitoring and control products
and features. Microsoft is promoting its software distribution
functionality. A handful of development tools vendors are expanding
their products to address direct management of application
modules. In all of the products and architectures becoming
available, however, four major alternatives are apparent. The four
major alternatives are:
|
(Sun Microsystems, Inc.)(1997).iso/products/Unify/gifs/seyb10004.gif)
| Approach #1: Network & Systems Management With Event Correlation | DESCRIPTION OF THE APPROACH. The first
approach available in the market is to use conventional network and
systems management products with event correlation to monitor and
control applications. (See Illustration AM-3.) The approach employs
an SNMP network management platform and agents to monitor and
control log files, caches, disks, and other operating systems
facilities. The information obtained from the network and systems
facilities is then fed into an event correlation engine that
matches sequences of events to likely causes. The user organization
must usually define the majority of the formulae used to correlate
events. Defining event correlation formulae can be a painstaking
task requiring great skill. EFFECT ON APPLICATION DEVELOPMENT. Most application developers will have minimal involvement in Approach #1. Developers will be called upon to describe how their application code interacts with operating systems and network resources. Management specialists will then use this information to design either agents, event correlation formulae, or both to manage the application. PRIMARY PROMOTERS. The vendors that promote use of conventional management with event correlation are those that sell so-called management platforms: HP, IBM, Sun, and others. These vendors are trying to expand the range of resources they can manage beyond their current base in network device management. Their primary goal is to accommodate a wide variety of management information obtained from a number of protocols and other sources. Event correlation is the technique for extracting meaning from diverse management data. HOW APPROACH #1 STANDS UP TO THE CRITERIA. The first approach-conventional network & systems management-doesn't adequately provide the six functions required for application management.
|
| Approach #2: Application Management APIs | DESCRIPTION OF APPROACH #2. The API
approach employs a published interface for collecting management
information from applications and controlling their deployment and
ongoing operation. (See Illustration AM-3.) The interface defines a
data model for use in describing the application, its components,
and key management data, a file format to store and distribute
information about the application, and conventions governing use of
the API. An application management API must be implemented by
back-end management platforms and applications to be useful.
Developers employ the API to forward monitoring, control, and
tuning information about their applications to these back-end
applications, and to transmit commands and data values from
management applications to the application itself. Most application
management APIs are closely associated with a single vendor's
management products. EFFECT ON APPLICATION DEVELOPERS. Application developers can employ application management APIs in two ways. First, they can use bundled functionality within their applications. For example, an API may provide a generic log file monitor that the developer can use to provide access to status information about the application. Second, APIs support creation of custom events and management tasks by developers. This programming is difficult and time-consuming. The developer must undertake the programming for each application. PRIMARY PROMOTERS. The primary promoters of application management APIs are Tivoli, BMC Corp., HP, and other systems management vendors. These vendors hope to expand beyond system administration to application management. Microsoft is also promoting the API approach with its System Management Server (SMS). HOW APPROACH #2 STANDS UP TO THE CRITERIA. The application management API is surprisingly weak when measured using the six requirements.
|
(Sun Microsystems, Inc.)(1997).iso/products/Unify/gifs/seyb10005.gif)
| Approach #3: Database-Server Management | DESCRIPTION OF APPROACH #3. The third
application management option is database-server management
products. All of the major database vendors have fairly
sophisticated products to help database administrators (DBAs)
monitor, control, and tune database servers from a single console.
These management products can be adapted to the challenge of
application management. Several of the vendors are adding
configuration management and software distribution for clients to
their database server management products, for example. Most
vendors also plan to add performance management features as well.
(See Illustration AM-4.) EFFECT ON APPLICATION DEVELOPERS. Database-server management products are primarily designed for use by DBAs. Application developers will have limited involvement with the products. Database-server management products give developers only low-level APIs with which to define application-specific management data. PRIMARY PROMOTERS. The major vendors of database servers promote Approach #3-for obvious reasons. The database vendors view database-server management as an opportunity to both improve the tools they provide to DBAs and an opportunity to build their franchises within customer sites. Oracle, for example, recently announced Workgroup Manager, a database-server management product that Oracle positions against Tivoli and Microsoft's SMS! Sybase's product is the Enterprise SQL Manager. Compuware's EcoTools division, BMC's Patrol group, and other third-party vendors promote a database-independent approach to server management. HOW APPROACH #3 STANDS UP TO THE CRITERIA. Database-server management products are not a general-purpose solution for application management. These products manage modules that are resident in database servers only.
|
| Approach #4: Application Management Architectures | DESCRIPTION OF APPROACH #4. The final
approach is a comprehensive architecture to link the developer's
environment-a development tool-and management environments-consoles
and management applications. In this approach, developers define
the management information important to understanding the operation
of their code. Developers have two options to create these events.
First, they can define management events using their familiar
application development tools, not arcane APIs. Second, developers
can use the events and statistics that have been pre-built by the
vendor. In both cases, the development environment generates the
required structures to represent the application, and then forwards
management information to external management products for
presentation and other actions. The mechanism for the interchange
between the application and the external management products is an
agent. This structure gives the architecture great flexibility. To
add support for a new external management system requires only the
addition of an agent to represent that system. The number of
management functions supported by comprehensive application
management architectures is limitless. (See Illustation AM-4) EFFECT ON APPLICATION DEVELOPERS. The comprehensive application management architecture gives developers the ability to actively participate in monitoring and control of their applications. Developers participate by choosing which of the pre-built events provided by the vendor are best to manage the application. Developers can also create their own events when necessary. In effect, developers are helping to document their applications for the operations staff. Because the operations staff will get direct readings of the application's status, they'll be able to act on problems with greater speed and efficiency. PRIMARY PROMOTERS. The primary promoters of the comprehensive application management approach are a handful of application development tools vendors. Several vendors are trying to deliver such architectures for their products. Unify is the first vendor to announce a comprehensive architecture for application management. HOW APPROACH #4 STANDS UP TO THE CRITERIA. The comprehensive architecture approach is designed specifically to enable application management.
|
| The Fourth Approach Stands Out | The following chart summarizes how well the four approaches to application management meet the six requirements outlined above. Of the four approaches, the comprehensive application management architecture is the strongest-by design. These architectures are designed to satisfy the requirements of direct application management. The table employs a simple grading system. For each criteria, an approach receives a score of weak, strong, or not addressed. A brief explanation is also provided. |
| 1. Simple generation of application specific management events. | Weak.
Arcane development interfaces only. | Weak.
Development interfaces require high skill. | Weak.
Development interfaces require high skill. | Strong.
By design; via development tools. |
| 2. Support for management of multiple applications. | Weak.
Conventional management systems don't recognize applications. | Strong.
APIs designed to support multiple applications. | Strong.
Designed to support multiple database applications. | Strong.
By design. |
| 3. Support for external management systems. | Weak.
Support only for SNMP and/or CMIP. | Weak.
Initial versions support limited range of systems. | Weak.
Vendors have interest in limiting integration with other products. | Strong.
Architecture relies on agents, a flexible approach. |
| 4. Scaleable architecture. | Strong.
With some limits for SNMP platforms. | Not Addressed.
Scalability depends on implementation of the API, and will vary. | Strong.
Products are designed to manage large distributed database environments. | Strong.
The architecture includes infrastructure for data filtering and prioritizing. |
| 5. Easily extensible architecture. | Weak.
Extensions are not easy. | Weak.
APIs often provide extension facilities, but they are difficult to use. | Weak.
Custom extensions are not easy. | Strong.
Extension by addition of agents and events using 4GL-like facilities. |
| 6. Comprehensive architecture. | Weak.
Most solutions are limited to fault management. | Weak.
APIs are vendor-centric, and don't support the 5 disciplines. | Weak.
Focus is on database server code. | Strong.
Includes support for the five disciplines. |
| AppMan: A Comprehensive Architecture for Direct Application Management | Unify Corp.'s AppMan is a prototypical application management architecture. AppMan supplements Unify's VISION application development and execution environment, providing links between the development tools, running applications, and external management products. AppMan assumes that organizations prefer to manage applications using the same tools they employ to monitor and control systems and networks. Unify does not seek to replace these tools. The result: Centralized management of client/server applications, systems, and networks. AppMan is an architecture to enable direct monitoring, control, and tuning of application modules. Unify designed AppMan after initially setting out to integrate Unify with individual third-party management products. The company quickly realized that a general architecture to integrate tools with management platforms and applications was preferable to pairwise integration efforts. [AppMan is now included with the VISION development environment]. However, AppMan is actually independent of development tools. In the future, it could be used to support a variety of development tools. Independence is a good test of an architecture's quality and completeness. AppMan is designed to move information from development environments-Unify VISION, in the first case-to management tools. AppMan takes events and other information generated by tools on the front-end, collects that information, and passes the information to management tools, transforming its format as needed. The heart of the architecture is a series of agents (see Illustration AM-5). The product also includes a toolkit for creating agents, and a runtime environment. |
| AppMan Agents | Agents are the interface between AppMan and external management systems. An AppMan agent accepts information from the AppMan runtime environment, and generates file formats, message formats, and other data structures required by an external management system. Each agent addresses a management discipline, such as fault management or performance management, and a format for information within that discipline. For example, the first release of AppMan will include an agent for Tivoli Courier, a software distribution application. The Courier agent addresses software distribution functions within Tivoli's formats and conventions for that management discipline. Some agents are runtime facilities. Event and performance management, for example, operate as applications run, collecting information and statistics in real-time, and forwarding that information to external tools. Developers make use of other agents at deployment time. The software distribution agent is a deployment-time agent. Unify's use of agents is a variation on the traditional manager-agent architecture, in which agents represent individual managed objects. In AppMan, agents represent external management systems. The variation suits the purpose, and the design is very flexible. The beauty of agent-based architectures is that agents can come and go as needed to accommodate new capabilities, new vendors, and new user requirements. |
| External Management Systems Supported by Unify AppMan | Unify assumed, in designing AppMan, that customers
will want to support many third-party management products without
having to build agents themselves. This is a good assumption. Unify
will provide several pre-built AppMan agents to support immediate
integration with the management platforms listed in the table
below. Unify also plans to make other agents available in the
second release of AppMan.
|
| The Agent Toolkit and the APIs | The AppMan Agent Toolkit gives developers the means to create their own agents. The basis for the toolkit is Unify's documented APIs for agents. The APIs define the functions required to build agents to address management functions. Unify has segmented the management disciplines into six management functions: event management, performance management, software distribution, security, administration, and software asset management. The AppMan Agent Toolkit is a C-language facility. |
| The AppMan Runtime Environment | AppMan has a runtime environment to support the operation of agents and the gathering of management information from applications. The AppMan runtime is designed to scale, using the concept of active forwarding. The runtime collects events and statistics about a running application, and, at a user-defined interval, forwards the information to a given agent. The agent then forwards the information to the external management system. This design is efficient, and relatively unobtrusive to the application's processing. AppMan does not require constant polling of agents to obtain information about applications. Polling is the design employed in SNMP systems, and it has been proven to sap network resources. The AppMan runtime environment also solves a short-term platform coverage gap for users. Most Unify VISION applications are deployed on Windows clients and Unix servers. To monitor, control, and tune these applications, users must collect information from multiple platforms. Unfortunately, most of the client/server management products are just becoming available for Windows 3.x and Windows 95 clients, and that means there will be a gap in platform coverage during 1996. Unify is filling this gap with a small Windows proxy agent, or client, in the first release of AppMan. Within a year, however, Unify expects to use the infrastructures provided by third-party management tools. |
| Using AppMan: The Link to Unify | For Unify VISION developers, AppMan will appear to be
an extension of their development environment-if they see it at
all. Developers will see AppMan only when performing software
distribution and when designing custom events. Unify's primary goal
in building AppMan was unlocking the management data that VISION
collects as a matter of course, and making that information
available to external management systems. VISION exposes 400 events
and 60 performance management statistics. Some examples include:
|
| AppMan Console: A Basic Facility | Unify also ships a basic console with AppMan-strictly for the sake of customer convenience. The AppMan Console is not a general-purpose application management environment, such as Tivoli Enterprise Console or BMC's Patrol. Rather, it is a tool to ease management of VISION application partitions. The AppMan Console supports visual display, deployment, starting, stopping, and restarting partitions. In the future, Unify plans to also include basic fault and performance management viewing in its console. [Included in Unify VISION 3.0] . |
| Unify AppMan Compared to the Competition | Unify's approach to direct application management is more comprehensive than the solutions offered by other development tools vendors. Forté and Oracle, for example, are adding direct application management features to their environments. However, both companies support a subset of the management functions supported by AppMan. Neither Forté nor Oracle has built a comprehensive architecture for supporting external management systems, either, although they offer pairwise integration with specific products. PowerSoft is also pursuing pairwise integration-with Tivoli. The two companies are working together to build support for Tivoli's Application Management Specification into PowerBuilder. This is a useful effort. However, it is not a general architecture that allows PowerSoft to integrate its tools easily with a variety of third-party management tools. |
| Insist on a Comprehensive Architecture for Direct Application Management | As organizations continue to employ client/server
technology for their most important new applications, the monitoring,
control, and tuning of those applications has become a crucial
need. The new reality of client/server is the need for management
facilities that are efficient, expandable, and easy to use. Meeting
this need will require new thinking about management. Application management is not necessarily detective work using evidence gathered from low-level network devices and operating systems. It is direct monitoring, control, and tuning of application modules. Application management is also not restricted to software distribution and configuration control. Application management is a comprehensive problem, requiring a carefully designed solution. The presence of existing tools and skill sets means that neither application developers nor development tools vendors can offer isolated solutions. They must be adaptable. One approach to client/server application management stands out from all of the others: the comprehensive architecture discussed in this paper. The other alternatives aren't real alternatives at all, although they are positioned as such by vendors. Only the direct application management architecture allows management to be built into client/server modules without requiring big new investments in technology and skills. Only direct application management architectures ensure that management of client/server modules will complement existing investments in monitoring and control technology. When evaluating client/server management solutions, insist on an architecture that addresses the problem by design. Insist on a comprehensive architecture, not a partial solution or piecemeal approach. |